Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.555

Text File | 1996-02-12 | 28KB | 597 lines

Frequently Asked Questions (FAQS);faqs.555



    Motif++ is a public-domain library that defines C++ class wrappers for
Motif 1.1; it adds an "application" class for, e.g., initializing X, and also
integrates WCL and the Xbae widget set. This work was developed by Ronald van
Loon <[e-mail]> based on X++, a set of bindings done by the University
of Lowell Graphics Research Laboratory. The current sources are available from
decuac.dec.com (192.5.214.1) as /pub/X11/motif++.21.jul.92.tar.Z.

    The source code examples for Doug Young's "Object-Oriented Programming
with C++ and OSF/Motif" [ISBN 0-13-630252-1] do not include "widget wrappers"
but do include a set of classes that encapsulates higher-level facilities
commonly needed by Motif- or other Xt-based applications; check export in
~ftp/contrib/young.c++.tar.Z.
    Rogue Wave offers "View.h++" for C++ programmers using Motif; info:
1-800-487-3217 or [phone].
    A product called "Commonview" by Glockenspiel Ltd, Ireland (??)
apparently is a C++-based toolkit for multiple window systems, including PM,
Windows, and X/Motif.
    Xv++ is sold by Qualix (415-572-0200; fax -1300); it implements an
interface from the GIL files that Sun's OpenWindows Developers Guide 3.0
produces to Xview wrapper classes in C++.

    UIT is a set of C++ classes embedding the XView toolkit; it is intended
for use with Sun's OpenWindows Developers Guide 3.0 builder tool. Sources are
on export.mit.edu.au as UIT.tar.Z. Version 2 was released 5/28/92.

    Also of likely use is ObjectCenter (Saber-C++). And a reasonable
alternative to all of the above is ParcPlace's (formerly Solbourne's) Object
Interface.

[Thanks to Douglas S. Rand ([e-mail]) and George Wu ([e-mail]);2/91]

----------------------------------------------------------------------
Subject: 135)! Where can I obtain alternate language bindings to X?

    Versions of the CLX Lisp bindings are part of the X11 core source
distributions. A version of CLX is on the R5 tape [10/91]; version 5.0.2 [9/92]
is on export.lcs.mit.edu in /contrib/CLX.R5.02.tar.Z.

    The SAIC Ada-X11 bindings are through anonymous ftp in /pub from
stars.rosslyn.unisys.com (128.126.164.2).
    There is an X/Ada study team sponsored by NASA JSC, which apparently is
working out bindings. Information: [e-mail].
    GNU SmallTalk has a beta native SmallTalk binding to X called STIX (by
[e-mail]). It is still in its beginning stages, and
documentation is sparse outside the SmallTalk code itself. The sources are
available as /pub/gnu/smalltalk-1.1.1.tar.Z on prep.ai.mit.edu (18.71.0.38) or
ugle.unit.no (129.241.1.97).
    Prolog bindings (called "XWIP") written by Ted Kim at UCLA while
supported in part by DARPA are available by anonymous FTP from
export.lcs.mit.edu:contrib/xwip.tar.Z or ftp.cs.ucla.edu:pub/xwip.tar.Z.
These prolog language bindings depend on having a Quintus-type foreign function
interface in your prolog. The developer has gotten it to work with Quintus and
SICStus prolog. Inquiries should go to [e-mail]. [3/90]
    Scheme bindings to Xlib, OSF/Motif, and Xaw are part of the Elk
distribution; version 1.5a on export obsoletes the version on the R5 contrib
tape.
    x-scm, a bolt-on accessory for Aubrey Jaffer's "scm" Scheme interpreter
that provides an interface to Xlib, Motif, and OpenLook, is now available via
FTP from altdorf.ai.mit.edu:archive/scm/xscm1.05.tar.Z and
nexus.yorku.ca:pub/scheme/new/xscm1.05.tar.Z.

    Ada bindings to Motif, explicitly, will eventually be made available by
the Jet Propulsion Laboratories, probably through the normal electronic
means.  Advance information can be obtained from [e-mail],
who may respond as time permits.
    AdaMotif is a complete binding to X and Motif for the Ada language, for
many common systems; it is based in part upon the SAIC/Unisys bindings and also
includes a UIL to Ada translator. Info: Systems Engineering Research
Corporation, 1-800-Ada-SERC (well![e-mail]).

    Also: the MIT Consortium, although not involved in producing Ada
bindings for X, maintains a partial listing of people involved in X and Ada;
information is available from Donna Converse, [e-mail].

----------------------------------------------------------------------
Subject: 136)  Can XGetWindowAttributes get a window's background pixel/pixmap?

    No.  Once set, the background pixel or pixmap of a window cannot be
re-read by clients.  The reason for this is that a client can create a pixmap,
set it to be the background pixmap of a window, and then free the pixmap. The
window keeps this background, but the pixmap itself is destroyed.  If you're
sure a window has a background pixel (not a pixmap), you can use XClearArea()
to clear a region to the background color and then use XGetImage() to read
back that pixel.  However, this action alters the contents of the window, and
it suffers from race conditions with exposures. [courtesy Dave Lemke of NCD
and Stuart Marks of Sun]

    Note that the same applies to the border pixel/pixmap. This is a
(mis)feature of the protocol which allows the server is free to manipulate the
pixel/pixmap however it wants.  By not requiring the server to keep the
original pixel or pixmap, some (potentially a lot of) space can be saved.
[courtesy Jim Fulton, MIT X Consortium]

----------------------------------------------------------------------
Subject: 137)  How do I create a transparent window?

    A completely transparent window is easy to get -- use an InputOnly
window. In order to create a window which is *mostly* transparent, you have
several choices:
    - the SHAPE extension first released with X11R4 offers an easy way to
make non-rectangular windows, so you can set the shape of the window to fit the
areas where the window should be nontransparent; however, not all servers
support the extension.
    - a machine-specific method of implementing transparent windows for
particular servers is to use an overlay plane supported by the hardware.  Note
that there is no X notion of a "transparent color index".
    - a generally portable solution is to use a large number of tiny
windows, but this makes operating on the application as a unit difficult.
    - a final answer is to consider whether you really need a transparent
window or if you would be satisfied with being able to overlay your application
window with information; if so, you can draw into separate bitplanes in colors
that will appear properly.

[thanks to der Mouse, [e-mail], 3/92; see also
The X Journal 1:4 for a more complete answer, including code samples for this
last option]

----------------------------------------------------------------------
Subject: 138)  Why doesn't GXxor produce mathematically-correct color values?

    When using GXxor you may expect that drawing with a value of black on a
background of black, for example, should produce white. However, the drawing
operation does not work on RGB values but on colormap indices. The color that
the resulting colormap index actually points to is undefined and visually
random unless you have actually filled it in yourself. [On many X servers Black
and White often 0/1 or 1/0; programs taking advantage of this mathematical
coincidence will break.]
    If you want to be combining colors with GXxor, then you should be
allocating a number of your own color cells and filling them with your chosen
pre-computed values.
    If you want to use GXxor simply to switch between two colors, then you
can take the shortcut of setting the background color in the GC (graphics
context) to 0 and the foreground color to a value such that when it draws over
red, say, the result is blue, and when it draws over blue the result is red.
This foreground value is itself the XOR of the colormap indices of red and
blue.

[Thanks to Chris Flatters ([e-mail]) and Ken Whaley
([e-mail]), 2/91]

----------------------------------------------------------------------
Subject: 139)  Why does every color I allocate show up as black?

    Make sure you're using 16 bits and not 8.  The red, green, and blue
fields of an XColor structure are scaled so that 0 is nothing and 65535 is
full-blast. If you forget to scale (using, for example, 0-255 for each color)
the XAllocColor function will perform correctly but the resulting color is
usually black.

[Thanks to Paul Asente, [e-mail], 7/91]

----------------------------------------------------------------------
Subject: 140)  Why can't my program get a standard colormap?
I have an image-processing program which uses XGetRGBColormap() to get the
standard colormap, but it doesn't work.

    XGetRGBColormap() when used with the property XA_RGB_DEFAULT_MAP does
not create a standard colormap -- it just returns one if one already exists.
Use xstdcmap or do what it does in order to create the standard colormap first.

[1/91; from der Mouse ([e-mail])]

----------------------------------------------------------------------
Subject: 141)  Why does the pixmap I copy to the screen show up as garbage?

    The initial contents of pixmaps are undefined.  This means that most
servers will allocate the memory and leave around whatever happens to be there
-- which is usually garbage.  You probably want to clear the pixmap first using
XFillRectangle() with a function of GXcopy and a foreground pixel of whatever
color you want as your background (or 0L if you are using the pixmap as a
mask). [courtesy Dave Lemke of NCD and Stuart Marks of Sun]

----------------------------------------------------------------------
Subject: 142)  How do I check whether a window ID is valid?
My program has the ID of a window on a remote display. I want to check whether
the window exists before doing anything with it.

    Because X is asynchronous, there isn't a guarantee that the window
would still exist between the time that you got the ID and the time you sent an
event to the window or otherwise manipulated it. What you should do is send the
event without checking, but install an error handler to catch any BadWindow
errors, which would indicate that the window no longer exists. This scheme will
work except on the [rare] occasion that the original window has been destroyed
and its ID reallocated to another window.

[courtesy Ken Lee ([e-mail]), 4/90]

----------------------------------------------------------------------
Subject: 143)  Can I have two applications draw to the same window?

    Yes. The X server assigns IDs to windows and other resources (actually,
the server assigns some bits, the client others), and any application that
knows the ID can manipulate the resource [almost any X server resource, except
for GCs and private color cells, can be shared].
    The problem you face is how to disseminate the window ID to multiple
applications. A simple way to handle this (and which solves the problem of the
applications' running on different machines) is in the first application to
create a specially-named property on the root-window and put the window ID into
it. The second application then retrieves the property, whose name it also
knows, and then can draw whatever it wants into the window.
    [Note: this scheme works iff there is only one instance of the first
application running, and the scheme is subject to the limitations mentioned
in the Question about using window IDs on remote displays.]
    Note also that you will still need to coordinate any higher-level
cooperation among your applications.
    Note also that two processes can share a window but should not try to
use the same server connection. If one process is a child of the other, it
should close down the connection to the server and open its own connection.

[mostly courtesy Phil Karlton ([e-mail]) 6/90]

----------------------------------------------------------------------
Subject: 144)  Why can't my program work with tvtwm or swm?

    A number of applications, including xwd, xwininfo, and xsetroot, do not
handle the virtual root window which tvtwm and swm use; they typically return
the wrong child of root. A general solution is to add this code or to use it in
your own application where you would normally use RootWindow(dpy,screen):

/* Function Name: GetVRoot
 * Description: Gets the root window, even if it's a virtual root
 * Arguments: the display and the screen
 * Returns: the root window for the client
 */
#include <X11/Xatom.h>
Window GetVRoot(dpy, scr)
Display        *dpy;
int             scr;
{
Window          rootReturn, parentReturn, *children;
unsigned int    numChildren;
Window          root = RootWindow(dpy, scr);
Atom            __SWM_VROOT = None;
int             i;

  __SWM_VROOT = XInternAtom(dpy, "__SWM_VROOT", False);
  XQueryTree(dpy, root, &rootReturn, &parentReturn, &children, &numChildren);
  for (i = 0; i < numChildren; i++) {
    Atom            actual_type;
    int             actual_format;
    long            nitems, bytesafter;
    Window         *newRoot = NULL;

    if (XGetWindowProperty(dpy, children[i], __SWM_VROOT, 0, 1,
        False, XA_WINDOW, &actual_type, &actual_format, &nitems,
            &bytesafter, (unsigned char **) &newRoot) == Success && newRoot) {
            root = *newRoot;
            break;
        }
    }

    return root;
}

[courtesy David Elliott ([e-mail]). Similar code is in ssetroot, a
version of xsetroot distributed with tvtwm. 2/91]

A header file by Andreas Stolcke of ICSI on export.lcs.mit.edu:contrib/vroot.h
functions similarly by providing macros for RootWindow and DefaultRootWindow;
code can include this header file first to run properly in the presence of a
virtual desktop.

----------------------------------------------------------------------
Subject: 145)  How do I keep a window from being resized by the user?

    Resizing the window is done through the window manager; window managers
can pay attention to the size hints your application places on the window, but
there is no guarantee that the window manager will listen. You can try setting
the minimum and maximum size hints to your target size and hope for the best.
[1/91]

----------------------------------------------------------------------
Subject: 146)  How do I keep a window in the foreground at all times?

    It's rather antisocial for an application to constantly raise itself
[e.g. by tracking VisibilityNotify events] so that it isn't overlapped --
imagine the conflict between two such programs running.
    The only sure way to have your window appear on the top of the stack
is to make the window override-redirect; this means that you are temporarily
assuming window-management duties while the window is up, so you want to do
this infrequently and then only for short periods of time (e.g. for popup
menus or other short parameter-setting windows).

[thanks to der Mouse ([e-mail]); 7/92]

----------------------------------------------------------------------
Subject: 147)  How do I make text and bitmaps blink in X?

    There is no easy way.  Unless you're willing to depend on some sort of
extension (as yet non-existent), you have to arrange for the blinking yourself,
either by redrawing the contents periodically or, if possible, by playing games
with the colormap and changing the color of the contents.

[Thanks to [e-mail] (der Mouse), 7/91]

----------------------------------------------------------------------
Subject: 148)  How do I render rotated text?

    Xlib intentionally does not provide such sophisticated graphics
capabilities, leaving them up to server-extensions or clients-side graphics
libraries.
    Your only choice, if you want to stay within the core X protocol, is to
render the text into a pixmap, read it back via XGetImage(), rotate it "by
hand" with whatever matrices you want, and put it back to the server via
XPutImage(); more specifically:
    1) create a bitmap B and write your text to it.
    2) create an XYBitmap image I from B (via XGetImage).
    3) create an XYBitmap Image I2 big enough to handle the transformation.
    4) for each x,y in I2, I2(x,y) = I(a,b) where
        a = x * cos(theta) - y * sin(theta)
        b = x * sin(theta) + y * cos(theta)
    5) render I2
    Note that you should be careful how you implement this not to lose
bits; an algorithm based on shear transformations may in fact be better.
    The high-level server-extensions and graphics packages available for X
also permit rendering of rotated text: Display PostScript, PEX, PHiGS, and GKS,
although most are not capable of arbitrary rotation and probably do not use the
same fonts that would be found on a printer.
    In addition, if you have enough access to the server to install a font
on it, you can create a font which consists of letters rotated at some
predefined angle. Your application can then itself figure out placement of each
glyph.

[courtesy der Mouse ([e-mail]), Eric Taylor
([e-mail]), and Ken Lee ([e-mail]), 11/90;
Liam Quin ([e-mail]), 12/90]

    InterViews (C++ UI toolkit, in the X contrib software) has support for
rendering rotated fonts in X.  It could be one source of example code.
[Brian R. Smith ([e-mail]), 3/91]
    Another possibility is to use the Hershey Fonts; they are
stroke-rendered and can be used by X by converting them into XDrawLine
requests. [[e-mail], 10/91]

    The xrotfont program by Alan Richardson ([e-mail])
(posted to comp.sources.x July 14 1992) paints a rotated font by implementing
the method above and by using an outline (Hershey) font.

    O'Reilly's X Resource Volume 3 includes information from HP about
modifications to the X fonts server which provide for rotated and scaled text.

----------------------------------------------------------------------
Subject: 149)  What is the X Registry? (How do I reserve names?)

    There are places in the X Toolkit, in applications, and in the X
protocol that define and use string names. The context is such that conflicts
are possible if different components use the same name for different things.
    The MIT X Consortium maintains a registry of names in these domains:
orgainization names, selection names, selection targets, resource types,
application classes, and class extension record types; and several others.
    The list as of 7/91 is in the directory mit/doc/Registry on the R5
tape; it is also available by sending "send docs registry" to the xstuff mail
server.
    To register names (first come, first served) or to ask questions send
to [e-mail]; be sure to include a postal address for
confirmation.

[11/90; condensed from Asente/Swick Appendix H]
----------------------------------------------------------------------

David B. Lewis                     [e-mail]

        "Just the FAQs, ma'am." -- Joe Friday
--
David B. Lewis        Temporarily at but not speaking for Visual, Inc.
day: [e-mail]    evening: [e-mail]
Xref: bloom-picayune.mit.edu comp.windows.x:62130 news.answers:4669
Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!news.bbn.com!olivea!sun-barr!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!gumby!destroyer!cs.ubc.ca!alberta!art
From: [e-mail] (Art Mulder)
Newsgroups: comp.windows.x,news.answers
Subject: comp.windows.x: Getting more performance out of X.  FAQ
Summary: This posting contains a list of suggestions about what you can do to get the best performance out of X on your workstation -- without buying more hardware.
Keywords: FAQ speed X
Message-ID: <art.724532420@warspite>
Date: 16 Dec 92 19:00:20 GMT
Sender: [e-mail] (News Administrator)
Reply-To: [e-mail] (Art Mulder)
Followup-To: poster
Organization: University of Alberta, Edmonton, Canada
Lines: 556
Approved: [e-mail]
Nntp-Posting-Host: warspite.cs.ualberta.ca

Archive-name: x-faq/speedups
Last-modified: 1992/12/16

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

        HOW TO MAXIMIZE THE PERFORMANCE OF X -- monthly posting

  More RAM, Faster CPU's, More disk space, Faster Ethernet...  These are
  the standard responses you get when you ask about how to make your
  workstation go faster.

  Well, more hardware isn't always an option, and I wonder if more
  hardware is really always even a necessity.

  This "FAQ" list is a collection of suggestions and ideas from different
  people on the net on how you can the best possible performance from your
  workstation, WITHOUT PURCHASING MORE HARDWARE.

  This document is specifically concerned with X.  I realize that there are
  a whole host of other factors that affect the performance of a
  workstation.   Perhaps at some point, this document will grow into a
  generalized "System Performance Tuning" document, but for now our focus is
  on X.
    [ Note: People seriously interested in the whole area of system
    performance, might want to look at the O'Reilly nutshell book
    "System Performance Tuning" by Mike Loukides.  I've seen it,
    but not read it, so I can't comment on its content.  --ed.]

-----------------
Table of Contents
-----------------
  1. What about the "Other X FAQ"?
! 2. Window Managers
  3. The X Server
       Which Server?
       Starting your Server
       Fonts
!      About the Resources File
       Define Your Display Properly
! 4. Clients
!      A Better Clock for X
       A Better Terminal Emulator for X
  5. Miscellaneous Suggestions
       Pretty Pictures
       A Quicker Mouse
       Programming Thoughts
!      Say What!?
  6. Other Sources of Information
  7. Author & Notes

-----------------------------
What about the "Other X FAQ"?
-----------------------------

  David B. Lewis ([e-mail]) maintains the informative and
  well written "comp.windows.x Frequently Asked Questions" document.
  Its focus though, is on generally useful X information, while this
  FAQ is concerned with the issue of performance.

  The comp.windows.x FAQ does address the issue of speed, but only with
  regards to the X server.  The gist of that topic seems to be:
    "Use X11R5, it is faster than R4".
  (Please see the X FAQ for complete details).

  Performance is a subjective issue.  The individual user must balance
  `speed' versus `features' in order to come to a personal decision.
  Therefore this document can be be expected to contain many subjective
  opinions in and amongst the objective facts.

---------------
Window Managers
---------------

  There are a lot of window managers out there, with lots of different
  features and abilities.  The choice of which to use is by necessity a
  balancing act between performance and useful features.  At this
  point, most respondents have agreed upon "twm" as the best candidate
  for a speedy window manager.

  A couple of generic tricks you can try is turning off unnecessary
  things like "zooming" and "opaque move".  Also, if you lay out your
  windows in a tiled maner, you reduce the amount of cpu power spent
  in raising and lowering windows.
                    Joe English ([e-mail])

  I've found that a good font for tiling is 7x13 (aka:
  -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1 ) It is
  the biggest font I have found that I can use on a SPARC ELC and still
  get two 80 column terminal windows side-by-side on the display with
  no overlap.  Other suggestions will be accepted.

------------
The X Server
------------

Which Server?
- - - - - - -

  Doesn't the old saying go: "Use the right tool for the job"?  This
  applies to the X11 server also.  Make sure that your server is a
  proper match for your hardware platform.  If you have a monochrome
  monitor, use a monochrome X11 server.

  On my Monochrome Sun ELC, I haven't noticed much difference between
  the Xsun (colour) server and XsunMono, however it was pointed out to
  me that XsunMono is about 800k smaller and therefore should contribute
  to less paging.
         [ thanks to: Jonny Farringdon ([e-mail]),
                        Michael Salmon ([e-mail]) ]

  How your server was compiled can also make a difference.  Jeff Law
  ([e-mail]) advises us that on a Sun system, X should
  be compiled with gcc2.* or with the unbundled Sun compiler, and *not*
  use the the SunOS 4.1.1 bundled compiler.  You can expect to get
  "*very* large speedups in the server" that way.  I would assume that
  similar results would occur if you used one of the other popular
  high-quality commercial compilers on the market.

Starting your Server
- - - - - - - - - - -

  Joe English ([e-mail]) :
    If you start up a lot of clients in your .xsession or whatever, sleep
    for a second or two after launching each one.  After I changed my
    .xclients script to do this, logging in actually took *less* time...
    we have a heavily loaded system without much core, though.

  This sounds crazy, but I tried it, and it works!

  Warner Losh ([e-mail]) provided me with a good explanation of
  why this works, which I have summarized here:

    When you start up an X server it takes a huge amount of time to
    start accepting connections.  A lot of initialization is done by
    the server when it starts.  This process touches a large number of
    pages.  Any other process running at the same time would fight the
    server for use of the CPU, and more importantly, memory.  If you
    put a sleep in there, you give the Server a chance to get itself
    sorted out before the clients start up.

    Similarly, there is also a lot of initialization whenever an X
    client program starts: toolkits registering widgets, resources
    being fetched, programs initializing state and "databases" and so
    forth.  All this activity is typically memory intensive.  Once this
    initialization is done ("The process has reached a steady state"),
    the memory usage typically settles down to using only a few pages.
    So, by using sleeps to stagger the launching of your clients in
    your .Xinitrc , you avoid them "fighting" each other over your
    workstations limited resources

  This is most definitely a "Your Mileage May Vary" situation, as there
  are so many variables to be considered: available RAM, local swap
  space, load average, number of users on your system, which clients
  you are starting, etc.

  Currently in my .xinitrc I have a situation like:
    (sleep 1; exec xclock ) &
    (sleep 1; exec xbiff ) &
    (sleep 1; exec xterm ) &
    (sleep 1; exec xterm ) &
    (sleep 1; exec xterm ) &

  I've experimented with:
    (sleep 1; exec xclock ) &
    (sleep 2; exec xbiff ) &
    (sleep 3; exec xterm ) &
    (sleep 4; exec xterm ) &
    (sleep 5; exec xterm ) &

  I've even tried:
    (sleep 2; exec start_X_clients_script ) &
  and then in start_X_clients_script I had:
    (sleep 1; exec xclock ) &
    (sleep 1; exec xbiff ) &
    (sleep 1; exec xterm ) &
    (sleep 1; exec xterm ) &
    (sleep 1; exec xterm ) &

    [ The idea with this last one was to make sure that xinit had
    completely finished processing my .xinitrc, and had settled down
    into a "steady state" before the sleep expired and all my clients
    were launched. ]

  All of these yielded fairly comparable results, and so I just stuck with
  my current setup, for its simplicity.  You will probably have to
  experiment a bit to find a setup which suits you.

Fonts
- - -

  Loading fonts takes time, and RAM.  If you minimize the number of fonts
  your applications use, you'll get speed increases in load-up time.

  Farrell McKay ([e-mail]) :
    One small point I've noticed (not specifically related to R5) is that
    clients will always start up more quickly if they don't have to load a
    new font into the server.  So I only use two or three fonts throughout
    the whole of my X environment.  Sometimes I need to use a Kanji font
    (for my work) at intervals throughout the day, so in the morning I
    start up xfd with that font (that loads it into the server), iconify
    it, and leave it there for the rest of the day.  Pre-loaded fonts sure
    cut down initialization time.

  Joe English ([e-mail]) :
    Carefully choose a small number of fonts (one fixed-width, one roman,
    one sans-serif, one large one, whatever else you need) and
    reconfigure all the applications you use to use only those fonts.
    This will conserve server resources and make applications start up
    faster.  Loading fonts takes a long time.